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SHARING THE PERSONAL INFORMATION OF A NETWORK USER WITH THE 
RESOURCES ACCESSED BY THAT NETWORK USER 

}^f^7 \ RELATED APPLICATIONS 

' I ThisVpplication is related to U.S. Provisional Application No. 60/160,874, filed 

October 22, 19&9 and entitled "Sharing A User's Personal Information," which application is 
incorporated by reference in its entirety. 



TECHNICAL FIELD 

This application relates to sharing a user's personal information — for example, 
personal preference information — with a third party in a networked computing environment. 



BACKGROUND 



The computer system 10D illustrated in Fig. 1 represents a typical hardware setup for 
executing software that allows usqrs to perform tasks such as communicating with other 
computer users, accessing various computer resources, and viewing, creating, or otherwise 
manipulating electronic content - that\s, any combination of text, images, movies, music or 
other sound, animations, 3D virtual worlds, and links to other objects. The system includes 
various input/output (I/O) devices (mouse 1^3, keyboard 105, display 107) and a general 
purpose computer 100 having a central processor unit (CPU) 121, an I/O unit 117, and a 
memory 109 that stores data and various programs such as an operating system 111, and one 
or more application programs 113. The computer system 100 also typically includes some 
sort of communications card or device 123 (e.g., a modem or network adapter) for 
exchanging data with a network 127 via a communications link 125 (e.g., a telephone line). 
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As shown in Fig. 2, a user of a computer system can access electronic content or other 
resources either stored locally at the user's own client system 202 (for example, a personal or 
laptop computer) or remotely at one or more server systems 200. An example of a server 
system is a hosrt computer that provides subscribers with online computer services such as e- 
5 mail, e-commerae, chat rooms, Internet access, electronic newspapers and magazines, etc. 
Users of a host computer's online services typically communicate with one or more central 
servers systems 200^lirough client software executing on their respective client systems 202. 

In practice, a server system 200 typically will not be a single monolithic entity but 
rather will be a network of interconnected server computers, possibly physically dispersed 
^ib from each other, each dedicated to its own set of duties an/or to a particular geographic 
II region. In such a case, the individual servers are connected by a network of communication 
yi links, in known fashion. 

= ^ A "browser" is an example of client software that enables users to access and view 

~ % electronic content stored either locally or remotely, such as in a network environment (local 
\{p area network (LAN), intranet, and wiae area network (WAN) such as the Internet). A 

browser typically is used for displayin&documents described in Hypertext Markup Language 
(HTML) and stored on servers connectecftto a network, e.g., the Internet. Technically, a web 
browser is a client program that uses the Hypertext Transfer Protocol (HTTP) to make 
requests of web servers throughout the Internet on behalf of the browser user. A web server 
20 contains, in addition to the HTML and other filtes it can serve, an HTTP server daemon, 
which is a program designed to wait for HTTP requests and handle those requests when 
received. 

Fig. 3 is a screenshot of a browser application u 00 (Netscape Navigator) displaying a 

typical HTML document, or web page 302. As shown therein, a single web page 302 may be 

3 
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composed of several different files potentially of different data types 304 (for example, text, 
graphicfe, images, virtual worlds, sounds, movies, etc.). In addition, a web page can include 
links 30(*pointing to other resources (for example, web pages or individual files) available 
on the network. Links 306 can take virtually any visual form, for example, they can appear 
5 either as a text string or as a graphical image or a combination thereof. Each link 306 has an 
associated URL pointing to a location on the network. When a user "clicks on" or otherwise 
selects a displaced link 306, the browser automatically will retrieve a web page or other 
resource corresponding to the link's associated URL and display it to, or execute it for, the 
user. \ 

jfo A user instructs a browser to access an HTML document, or webpage, by specifying a 

network address, or Uniform Resource Locator (URL), at which a desired document resides. 
URLs are defined in Internet standard RFC 1738 to include an indication of the protocol to 
be used and the location of a Resource on a web server. In response, the browser contacts the 
corresponding server hosting th^ requested webpage, retrieves the one or more files that 
1% make up the webpage, and then displays the webpage in a window on the user's computer 
l: screen. \ 

Web pages typically are transported using the HyperText Transfer Protocol (HTTP) 
as defined in Internet standard RFC 2068. HTTP is a set of rules for exchanging files (text, 
graphic images, sound, video, and other multimedia files) on the World Wide Web. Relative 
20 to the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols (which are 
the basis for information exchange on the Internet), WTTP is an application layer protocol. 

When a user of a web browser sends an HTTP request by typing in a URL or clicking 

on a hypertext link, the browser builds an HTTP request atad sends it to the address indicated 

by the URL. The HTTP server daemon in the destination server machine receives the request 

4 \ 
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^ /^ind, aft^ any necessary processing, the requested file is returned. The response is sent back 

to the browser where it can be displayed to the user. The HTTP protocol response includes 
various codes detailing the result of the request. For example, return code 404 indicates that 
the information requested was not found. For transactions requiring security, the HTTP 
5 connection can ce secured with encryption. This variant is known as Secure HTTP (HTTPS) 
or Secure SockenLayer (SSL). 

HTTPS (Secure Hypertext Transfer Protocol) is a web protocol developed by 
Netscape Inc. of Mountain View, California and implemented in several browsers. The 
HTTPS protocol encrypts and decrypts user page requests as well as the pages that are 
Mo returned by the web serveV HTTPS uses Netscape's Secure Socket Layer (SSL) as a sublayer 
!1i under its regular HTTP application layer. HTTPS uses port 443 instead of HTTP port 80 in 
m its interactions with the loweriayer, TCP/IP. SSL uses a key size of a predetermined number 
CI of bits (typically between 40 and 128) for the RC4 stream encryption algorithm, which is 
^= considered a minimal degree of encryption for commercial exchange. 

ij5 When visiting an electronic commerce merchant, a user typically is presented with a 

CS web page order form URL that starts Vith "https://", indicating the use of the HTTPS 

protocol. When sending the response, tne browser will use the HTTPS layer for encryption. 

The acknowledgement received from the server also will travel in encrypted form using 

HTTPS, and will be decrypted by the browser's HTTPS layer. 

20 HTTPS and SSL support the use of X.509 digital certificates from the server so that, 

if necessary, a user can authenticate (i.e., confirm the identity of) the sender. SSL is an open, 

nonproprietary protocol that Netscape has proposed as a standard to the World Wide Web 

Consortium (W3C). HTTPS is not to be confused withASHTTP, a security-enhanced version 

of HTTP developed and proposed as a standard by EIT. 

5 
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digital certificate is an electronic token that establishes the credentials of a party 
doing busmess or other transactions on the web. Certificates are issued by a certification 
authority ((JA). Typically, certificates contain a party's name, a serial number, expiration 
dates, a copyW the certificate holder's public key (used for encrypting and decrypting 
messages and digital signatures), and the digital signature of the certificate-issuing authority 
so that a recipient can verify that the certificate is real. Some digital certificates conform to a 
standard, X.509. Digital certificates can be kept in registries so authenticated users can look 
up other users 1 publiakeys. 

HTTP also includes a mechanism referred to as a "cookie," which is used for 
maintaining client side petsistent data. A cookie is a token, for example, a special text file, 
that a web site stores on a user's hard disk so that the web site can remember something 
about a user at a later time. Typically, a cookie records a user's preferences when using a 
particular site. Under HTTP, eaoh request for a web page is independent of all previous 
requests. For this reason, a web page server has no memory of what pages it has sent to a 
user previously or anything about thW user's previous visits. The cookie mechanism allows 
the server to store its own file on the ulser's own computer. The file is typically stored in a 
subdirectory of the directory used to insrall the browser software. The cookie subdirectory 
will contain cookie files for each web site ^sited by the user that uses cookies. Cookies are 
commonly used to keep track of which banned ads a user already has encountered. This 
allows web sites to rotate the banner ads sent an& thereby minimize repetition as the user 
browses through multiple pages on a site. CookiesVlso can be used to customize web pages 
based on a user's browser type or other information provided to the web site. Web users must 
agree to let cookies be saved on their computers by configuring their browsers to accept 
cookies. \ 
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Consumers can buy and sell products and services shown on web pages via electronic 
commerce (re-commerce") transactions. To enable these transactions, a consumer and 
merchant mikt exchange personal and financial information concerning the online 
transaction, suVh as their credit card, billing address and shipping address. Conventional 
5 payment systems associated with many Internet commerce sites therefore require customers 
to type their credit card and mailing information into an HTML form. 

Figs. 4A and 4B show an example of an e-commerce form 400. The information from 
the form 400 typically includes name 405, shipping address 410, billing address 415, and 
credit card number 420\This information is submitted to the merchant, who then uses the 

j i{b information to complete the transaction using various known fulfillment and delivery 

^ mechanisms. \ 

l i f Navigating and completing these forms involves a great deal of repetition and 

ist * associated inconvenience to users when providing name, shipping address, billing address, 
j=i and credit card data to merchant^. Completing electronic forms often is a tedious and error- 
;1f prone process. Furthermore, usingythese payment systems, customers visiting several online 
Ci stores must re-enter their payment/address information at each store where they make a 

purchase, many stores even requiring Choppers to re-enter their payment information on each 

subsequent visit. \ 

To facilitate the process of filling out forms, "form fillers" have been developed. 
20 These applications automate the filling of forms encountered when visiting web sites. The 
form filler recognizes forms in HTML and records the data entered in the fields when the 
user fills out the form for the first time. Then, wheui similar fields show up in subsequent 
forms, the form filler can use the recorded data to automatically fill out these fields. An 
example of such a form filler is built into Microsoft Internet Explorer 5.0. Figs. 5 A, 5B, and 
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5C smow a form filler application built into a browser automatically filling out the fields in an 
e-commerce form. Some form fillers further allow the user to maintain several "identities" to 
help protect privacy. Each identity keeps track of a separate set of form data that will be used 
to fill in nfew forms. 

A similar but more sophisticated approach to facilitating online transactions is the 
digital walletV A digital wallet is a software application that allows the user to input shipping 
and billing data once and reuse this information at many different web sites to complete a 
purchase. Digital wallets that fill merchant forms or directly transfer data to merchants have 
been successfully Wit into browsers in several ways, including as helper applications to 
browsers, stand-alone applications, and browser plug-ins. 

Once the digital wallet is set up, the user can store, manipulate, and pay for Internet 
purchases with various t^pes of payment instruments (e.g., credit cards or electronic cash). 

Client-based personal electronic wallets have been developed to relieve this burden. 
Client-based wallets store e-oommerce information for a particular user at the machine 
operated by that user. When tlmt machine interfaces a merchant website through the internet, 
e-commerce information stored in the local wallet may be transferred to the merchant. 
However, because client-based wallets reside on the user machine, these wallets are subject 
to the limitations of the machine upon\/hich they reside. For instance, security attacks on 
the user machine may be used to target tne wallets residing thereon. In addition, limitations 
on portability for the machine result in limitations for the wallet. 

SUMMARY 
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fne or more of the following advantages may be provided. The techniques and 
methods described here may enable the user to drastically reduce the amount of work 
required ta fill out forms on web pages. This may be accomplished in one or more of the 
following vwiys. First, multiple pages of content can be filled out without requiring the user 
5 to view each page. Presenting only those fields and forms that are not automatically 

completed mimmizes the work for users. Users can be selectively queried for any merchant- 
specific missina fields, thus optimizing the form filling process. Users need not inspect each 
form and approve its contents. Further, merchants using the techniques and methods 
described here mm be able to provide information that is tailored and customized for the 
.40 user, thus increasing the usefulness of the merchant's content to the user. 

3; Other advantages for the user include ease of use in that no additional software is 

^ required. Further, as the user is not tied to a single computer, the other benefits described 

:=l here can be realized from any computer capable of accessing the merchant's site, regardless 

jsi of its location. In additioii the user gains some security, as the invention reduces the risks 

lis associated with data sniffirlg on the user's local area network and accessing storage devices 

Cf attached to the user's compuW 

For the merchant, the techniques and methods presented here enable merchant to 
access specific information abouka customer's preferences and history. The merchant can 
use that information to customize the content presented. Merchants can track completed 
20 purchases in order to better handle service and information requests. Because the merchants 
can access the information using a well-defined protocol, merchants can easily modify forms 
without causing problems with many different types of software. Merchants can obtain 
demographic data for future targeted advertising. An intimate relationship between the 
merchant, the user, and the online service is fostered. 
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laese techniques and methods can be generalized and applied to any type of data 
(e.g., travelVpreferences), in addition to shipping, billing, and demographic data. In addition, 
they may be implemented using a system, method, software, or some combination thereof. 

Details \f one or more implementations are set forth in the accompanying drawings 
and the description below. Other features and advantages will be apparent from the 
description and drivings, and from the claims. 



DESCRIPTION OF DRAWINGS 



Fig. 1 shows a blook diagram of a computer system. 



Fig. 2 shows a typical network-computing environment. 



Fig. 3 shows a browserapplication displaying a typical web page. 



Fig. 4 A shows a browser displaying an e-commerce form. 



Fig. 4B shows the second page of the e-commerce form of Fig. 4A. 



Fig. 5 A shows exemplary results of using a form filler application. 



Fig. 5B shows the second page orexemplary results of Fig. 5 A. 



Fig. 5C shows the third page of exemplary results of Fig. 5 A. 



Fig. 6 is a host-to-host architecture for sharing e-commerce transaction information. 



Fig. 7A shows an authentication process. 



Fig. 7B shows the process for requesting purchase information. 



Fig. 7C shows the process for requesting credit \ard numbers. 
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Eig. 8 is a flowchart of the typical sequence of screens displayed to users. 
FiA 9 is a screenshot of a merchant's product ordering page. 
Fig. W) is a screenshot of the framework authentication page. 
Fig. 1 1 A is a screenshot of the framework registration page. 
5 Fig. 1 IB i\ the second page of the screenshot of Fig. 12 A. 

Fig. 12 is a sVreenshot of the merchant's order confirmation page. 
Fig. 13 is a screenshot of the framework edit preferences page. 
Fig. 14 is a screenshot of the framework edit credit cards page. 
^ Fig. 15 is a screensnpt of the framework edit addresses page. 
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Fig. 16 is a screenshouof the framework change security page. 



Fig. 17 is a screenshot ofithe framework delete preferences page. 



Fig. 18 is a screenshot of the framework customer service page. 



Fig. 19 is a screenshot of the merchant's choose addresses page. 



Fig. 20 is a screenshot of the merchant's order information page. 



Like reference symbols in the various drawings may indicate like elements. 



DETAILED DESCRIPTION 

20 Quick checkout (QC) is a host-based system for sharing personal information of a 

network user with the resources accessed by that networl\user. QC generally involves either 

11 
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^)^P fcs ^ox botl^ of two data stores, referred to as passport and wallet. Passport and wallet are host- 
based ejections of routinely requested personal billing, shipping and demographics 
information (hereinafter "personal information"). They may be maintained independently or 
collectives A user with a populated passport or wallet may choose to pass selected 
5 information ro web sites, automatically or with very little effort, to enable an enhanced 
browsing experience or to assist in the completion of an online transaction. 

For instance, when merchants offer QC as a payment option and the consumer elects 
to invoke QC, theVaerchant simply passes the order information to a pre-determined SSL- 
enabled QC form that is then displayed to the consumer. Payment information and shipping 
^0 address are sent from the QC database to the QC form, and the form is confirmed, rejected or 
modified by the consumer. In this manner, the consumer need not redundantly enter payment 
information for each transaction or each merchant. Rather, they may rely on the wallet for 
this information, merely confirming its accuracy. As will be explained in greater detail 
k» below, when the wallet included several options for payment, shipping, etc., the consumer 
ilfe may establish default information^ and has the ability to select desired information from 
;~J among that stored. 

This host-based system facilitates seemless integration with other merchant services 
as well as the surrounding wallet/passport provider environment. Because the wallet and 
passport are host-based, they are inherently portable, updateable, secure and simple to setup 
20 and use. 



QC can be used to share many different pieces of a user's personal information, 

before and during an e-commerce transaction. For instance, using QC, selected user 

information may be shared with merchant servers uponYser's access to their web sites or 

later when performing an e-commerce transaction. More specifically, upon access to a 

12 
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merchant's web site, it is possible to share personal information to enable the merchant to 
personalize the content and services provided to the user. In this sense, QC can share 
virtually any other type of personal information, such as travel preferences, demographic 
information, food choices, and medical information. Thereafter, upon checkout, it is possible 
to share personal information of a more specific nature, generally concerning e-commerce 
information, fior instance, commercial information such as user name, address, and credit 
card information can be shared when appropriate to further e-commerce transactions. Each 
user's informations is stored in a "profile" that can be updated frequently. This information 
can be stored in any\proprietary or commercially available relational or object database 
f=40 management system (E^BMS), such as provided by Oracle, Inc. or Informix, Inc. 

Fig. 6 shows one Potential architecture of the framework, known as a "host-to-host" 
S% architecture. This architecture leaves the client computer 601 unmodified. The client 
q) computer 601, network host and the preferences server 603 can communicate with each 

other to exchange user preferences information efficiently with a minimum of user 
jib interaction. Once the preferences server 603 authenticates the user, the network host 602 can 

: s : \ 

directly communicate with the preferences server 603. 

HTTPS is generally used as a transport for requests and responses; however, other 
protocols could also be used as transport mechanisms. Input parameters in requests and 
return values must be URL-encoded, to ensute that nonstandard characters are properly 
20 transmitted over the Internet. Furthermore, retul^i codes from the requests may be used to 
verify their success. 

Although the framework does not require a raced sequence of requests from network 

hosts, communications between the user, the merchant\and the framework typically follow a 

particular pattern, illustrated in Figs. 7 and 7A, 7B, and l\. The basic pattern is to 

13 
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au&enticate the user 710, request purchase information 720, request payment information 
730, and finally to place the order 740. Each of these steps is described further below with 
respectVo Figs. 7A-7C, which shows client computer 701, merchant web server 702, 
preferences server 703, preferences database 704 and network 705. 

Figi 7 A shows the exchange of messages between the user, merchant, and the 
framework server during the authentication step 710. First, in step 710a, the merchant web 
server 702 provides a browser at client computer 701 access to its web page. The user is able 
to view the webWge and select a set of products or services offered by the merchant, and 
thereafter may invbke "QuickCheckout" to proceed with an e-commerce purchase. When 
QuickCheckout is invoked 710a, an authentication request 710b is sent to the preferences 
server 703 for authentication. After the user enters an authorized username and password, a 
session identifier is generated 710c and returned by the preferences server 703, and the user's 
browser 701 is again direcred to a web page on the merchant server 702. The session 
identifier is then sent 710d toVhe merchant, e.g., in the form of a cookie. For authentication 
throughout the remainder of the>session, this session identifier will be sent with each 
communication by the merchant server 702 to the preferences server 703 during the session. 

Fig. 7B shows the exchange ofcmessages that occurs while getting purchase 

information to the merchant server 702,\ccording to step 720. In step 720a, immediately 

after receiving an authentication confirmation from step 710, the merchant server 702 sends 

the session identifier with a request sent to th^preferences server 703 for information about 

the user. The merchant server 702 also sends an &509 SSL server certificate and a set of 

merchant preferences in the authentication request orsstep 720a. This certificate is used by 

the preferences server 703 to verify the identity of the merchant server 702 initiating the 

request for information. The preferences requested by the merchant server 702 of the 

14 
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preferences server 703 will be used to tailor later content and services provided by the 
merchant server 702 to the client computer 701. 

Jn step 720b, preferences information about the user is returned by the preferences 
server 703 to the merchant server 702. In step 720c, the information is formatted into a web 
page requesting confirmation of the information from the user at client computer 701. At this 
stage, only a portion of any previously entered credit card information is returned for security 
purposes, the reWned information providing enough information for the user to confirm 
and/or edit the useXinformation at this stage. 

Referring to Fig. 7C, the process 730 of obtaining payment information is described. 
At step 730a, once the preferences information is confirmed by the user, the merchant server 

702 sends the session identifier with a request for full payment information to the prefernces 
server 702. The user's full credit card information is then returned to the merchant server 702 
in step 730b. If the merchant sefyer 702 does not receive the information, it 702 can check 
the HTTP return status code and take appropriate action. Otherwise, once payment 
information is received by the merchant server 702, the transaction 853 may be processed 
with the credit card company in step 730c, and wait for authorization. The preferences server 

703 may also process the payment information with the credit card company. 

Finally, in step 740, the results of thiktransaction are sent to preferences server 703 
for customer service, record keeping, and order Vacking purposes. These results are stored in 
the database for use in future transactions. The merchant can check the HTTP return status 
code from the preferences server 703 and take approbate action if a failure occurs. 
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\hc flowchart of Fig. 8 shows primary paths involved in a typical transaction. The 
process alsi& includes appropriate error handling and alternative entry points when necessary. 
The sequencd of screens from the user's perspective is shown in Figs. 9-20. 

The firs\ step 901 in the process of Fig. 8 is for the user to browse the merchant's site 
and select some items for purchase. Fig. 9 shows such a screen with some products 1001 
selected for purchase. From this page, the user clicks the "AOL Quick Checkout" button 
1002. This button initiates the authentication request described above. 

The next step 90^in the process of Fig. 8 is to show the user the authentication page 
from the AOL site. This pa\e is shown in Fig. 10. If the user has an AOL account, he enters 
his screen name 1101 and password 1 102, then clicks on the "OK" button 1 103. If the user 
does not have an AOL account, \hen the user can register by clicking on the "Signup Now!" 
button 1 104. The registration step v03 in the process of Fig. 8 involves filling out a form, 
shown in Figs. 1 1A and 1 IB. The fofrn contains credit card information 1201, shipping 
information 1202, and account information 1203. After entering the required information, the 
user can register by clicking the "OK" button 1204. 

Once the user has either successfully authenticated or registered, the next step 904 in 

the process of Fig. 8 is to show the user a weotoage allowing him to review the order. Fig. 12 

shows how this page details the order 1301 and shows the default transaction information 

1302 provided by the framework server to the merchant. Only the last four digits of any 

credit card number 1303 are provided at this stage. From this screen, the user can choose 

shipping addresses by clicking on the "Choose Shippin^Vddresses" button 1304. The user 

can also choose to edit the transaction information by clicking on the "Edit Information" 

button 1305. When the user is satisfied with the addresses and transaction information, he 

can click on the "Complete AOL Quick Checkout" button 130otto confirm the transaction. 

16 
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B)\confirming the transaction, the user is authorizing the merchant to complete the 
transaction with the credit card company using the information displayed. 

Jf the user chooses to edit transaction information, the next step 905 in the process of 
Fig. 8 isVo show the user a set of edit screens. The first such screen is shown in Fig. 13 and 
allows the Vser to edit credit cards 1401, edit shipping addresses 1402, change security 
information 1403, delete AOL Quick Checkout settings 1404, and request customer service 
1405. Once tha user makes a selection, the appropriate screen is displayed. 

If in step)0O5 the user chooses to edit credit cards, the next step 906 in the process of 
Fig. 9 is to display \he screen shown in Fig. 14. This screen allows users to select a credit 
card for use in the cuVent transaction by selecting one of their currently defined credit cards 
1501 and clicking the "Use This Card" button 1502. Users can also edit a credit card's 
information by clicking tire "Edit This Card" button 1503. To edit a card or add information 
about a new credit card, the user can fill in the fields in the lower portion of the screen 1504. 
When the user is finished editing, he can click the "Add This Card" button 1505 to add the 
information to their profile. 

If in step 905 the user chooses to edit addresses, the process is very similar to that for 
editing credit cards. The next step 907Vn the process of Fig. 9 is to display the screen shown 
in Fig. 16. This screen allows users to select a shipping address for use in the current 
transaction by selecting one of the currentmdefined shipping addresses 1601 and clicking the 
"Use This Address" button 1602. Users can also edit an address by clicking the "Edit This 
Address" button 1603. To edit an address or add amew address, the user can fill in the fields 
in the lower portion of the screen 1604. When the usV is done editing, he can click the "Add 
This Address" button 1605 to add the information to th&profile. 
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Iffin step 905 of Fig. 8 the user chooses to change security information, the next step 
908 in the process of Fig. 8 is to display the screen shown in Fig. 16. This screen allows a 
user to enter Y 701 and confirm 1702 a new password by typing it into a form. A user can also 
change the enkil address 1703 associated with his profile. When the user is done editing, he 
5 can click the "OK" button to confirm the changes and continue. 

If in step)905 of Fig. 8 the user chooses to delete AOL Quick Checkout settings, the 
next step 909 in tire process of Fig. 8 is to display the screen shown in Fig. 17. This screen 
asks a user to confirtn that he wants to delete all of his credit card and shipping address 
information stored inVhe profile. A user can confirm this desire by clicking on the "Yes" 
j =jo button 1801. \ 

il If in step 905 of Fig. 8 the user requests customer service, the next step 910 in the 

] i: process of Fig. 8 is to display the screen shown in Fig. 18. This screen displays customer 
= " service information 1901 for all the companies associated with the AOL Quick Checkout 
f% service. This screen also offers additional information about the AOL Quick Checkout 
ut5 service 1902. \ 

iaS If the user in step 904 of Fig\8 decides to choose addresses instead of editing 

preferences, the next step 91 1 in the process of Fig. 8 is to display the screen shown in Fig. 
19. This screen shows the products 200l\elected by the user for purchase. The user can 
assign one of the addresses 2003 to each product by selecting the appropriate number in the 
20 pulldown menu 2002. Once the user has finished selecting addresses, he can finalize his 

choices by clicking on the "Use These Addresses\ button 2004. In addition, the user can edit 
addresses, as discussed above in step 907 of Fig. 8, oy clicking the "Edit Addresses" button 
2005. \ 



18 



Docket No.: 06975-062001 

V \ the user in step 904 of Fig. 8 is satisfied with the transaction selections, and has 

clicked th& button 1306 to complete the transaction, the next step 912 in the process of Fig. 8 
is to display a final page verifying that the transaction has been completed. This screen, as 
shown in Fi& 20, displays the transaction information 2101 that was used by the merchant to 
5 complete the credit card purchase. The display may include a confirmation string 2102 or 
order identification string 2103 for record keeping purposes. 

Fig. 21 shows an implementation as part of the AOL infrastructure. The figure shows 
the host-to-host architecture, as described above, with the addition of a proxy 2202. The 
proxy acts as an intermediary for all traffic between the host service computers and the 
=fo Internet. The proxy performs load balancing by switching connections to the least utilized 
]l hardware to ensure that a nigh degree of performance is maintained. The proxy also contains 
2% a list of hosts that can be redirected to internal AOL sites. The internal sites provide AOL 
Z% users with a more consistent look and feel. The internal sites can also be more tightly 
integrated with the AOL system\because they are under AOL control. 

] 5 In another implementation's users select all of the items they wish to purchase from 

:1 a particular merchant, the merchant collects and stores information about the purchase order, 
designated with an order identifier tha^s used to unify the order information. The order 
information is typically presented to the Consumer in a shopping cart upon request or at 
checkout. Using this order information, thdconsumer can confirm the contents of their 
20 shopping cart by invocation of QC or otherwise, as the order identifier ties any subsequent 
QC information to the order information stored fyy the merchant. 

Then, when the consumer launches QC usink an icon at the merchant website, the 

merchant authenticates the consumer as a QC user. Twsdo so, the merchant directs users to 

the AQC aolqc_auth url for authentication. If the GET t\this url returns successfully, the 
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merchant can be assured that the user has been appropriately identified and "logged in" as an 
AQK member. For example, the GET returns with a session identifier (aolqc_session_id) 
whichWrves as a key to the consumer account. Thereafter, the session id is passed with 
virtuallAevery backend call made by the merchant thereafter (e.g., to retrieve billing 
5 information for the customer, to enable editing by the customer). After the consumer is 

authenticated once by a merchant, they will not be redirected back to the authentication page 
until they havfe logged off of the AOL service. 

If authenticated, payment and shipping information is collected from QC. Preferably, 
the merchant mattes a host-to-host call to fetch a "pretty print" user-displayable version of 
rfO the user's default bming and shipping information from the QC, which version does not 
1] include all of the infonnation. The merchant then automatically produces a form that 
i{ includes order id and thai is posted to https://payment.aol.com/placeorder . For instance, a 
standard form might includte the parameters listed in Appendix A (see parameters spanning 
Ul pp 5-6 of AOL QC MerchanrConnectivity Specification filed with provisional application 
j1j5 number 60/160,874 filed October 22, 1999, which is incorporated by reference in its 
Cj entirety). Using the order_allow_multi_shipto field of the placeholder form, it is possible for 
a merchant to enable designation of Afferent shipping destinations for different aspects of the 
order (e.g., per unit or per item). Similarly, other fields may be duplicated to provide 
flexibility, as needed. 

20 In response to the placeorder form, available QC information is returned from the 

wallet and is posted at the merchant. Default QOmformation may be automatically selected 
to eliminate the need for additional user interaction (kiless editing is necessary). 
Alternatively, the consumer may be required to select among available QC information (e.g., 
credit card, shipping address information). In either case, \ subset of the sensitive QC 
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information from the wallet is provided to the merchant in response to the placeorder request. 
This\ubset includes enough for consumer to confirm/select, but intentionally omits some 
information to avoid possible security problems (trojan horses, etc). The selected subset of 
QC info re posted by QC host to the merchant site at the 
5 https://payWent.aol.com/order target url page (for future use in creating a confirmation page 
combining order and QC information). Fields from an exemplary form are listed on pgs. 6-7 
of AOL QC Merchant Connectivity Specification, which was filed with provisional 
application number 60/160,874 filed October 22, 1999, which is incorporated by reference in 
its entirety). If the merchant allows multiple shipping destinations for aspects of a single 
ijK) order, and the consumer has designated multiple destinations in the information provided by 
the merchant to the hoal, multiple posts may be made by the host to the 
https://payment.aol.eom/qg:der target url page, each post having the same order id number 
but different information where appropriate to accomplish the consumer order. 

^ After the consumer is redirected to the merchant site, the merchant provides an order 

! S$ confirmation page displaying the Vder and payment data. Specifically, the merchant 
z{ generates a form that displays the selected QC info and that queries the consumer to confirm 
the purchase. The confirmation page posts to a designated location known to wallet host, 
e.g., https://payment.aol.com/confinnorder \Fields from an exemplary form are listed in 
Appendix C (see list of parameters listed on pkof AOL QC Merchant Connectivity 
20 Specification). If the merchant allows multiple snipping destinations for aspects of a single 
order, the consumer has designated multiple destinations in the information provided by the 
merchant to the host, and multiple posts are made by theShost to the 

https://payment.aol.com/order target url page with the samfe order id number, the merchant 

will generate a confirmation page for each part of the order. Generally, information is 
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filtered before being returning to the merchant for confirmation (to prevent merchant from 
obtaiiMng enough financial info to complete transaction until after the complete transaction is 
confirmed by consumer). The merchant then displays screen requesting confirmation of 
shopping O^rt to selected credit card (with limited information being shown about credit 
card). 

After the o\der has been confirmed, three processes are performed: 

1 . thV customer is redirected to the http://payment.aol.com/order return url page 
which displays a message from the merchant thanking the customer for their order 

2. the merchant receives complete credit card information from the host along 
with other order information that is posted to target url specified in the order_target_url field 
of the initial post generated by the merchant. This information is used by the merchant to 
deliver the ordered goods. Ah examplary format for the order information is shown by 
appendix D (see pp8-10 of AOL QC Merchant Connectivity Specification). 

3. the merchant pushes order data to a URL accessible to the wallet host for 
customer service, record keeping and order tracking purposes. 

Using this system, and the ability to store and share personal information, it is 
possible to provide enhanced functionalfty such as parental controls, AOL rewards, gift 
reminders, purchase history, and keyword! 

Furthermore, integration with a servide provider enabling several screen-names for a 
single account allows the user to designate separate wallets/passports for different members 
on an account, each drawing on some common an^some independent information. For 
instance, several family members having different screen-names may each maintain 
independent wallets with separate e-commerce information while being provided access to a 
shared wallet having shared e-commerce information. In\his manner, selected credit cards 
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<A e-commerce information may be made accessible to some or all screen-names without 
shading all credit cards or other e-commerce information. Furthermore, when combined with 
the passport functionality, this model allows information to be maintained and communicated 
for each independent screen-name. 

Tnte techniques, methods, and systems described here may find applicability in any 
computing w processing environment in which electronic content may be viewed, accessed, 
or otherwise manipulated. For instance, the concept of sharing e-commerce transaction 
information between hosts in a networked computing environment could be applied 
whenever those preferences are useful to a third party, such as an e-commerce merchant. One 
such environment involves a computer system (e.g., a Microsoft Windows-based PC or 
Apple Macintosh) that\s connected to the Internet. 

Various implementations of the systems and techniques described here may be 
realized in digital electronic circuitry, or in computer hardware, firmware, software, or in 
combinations thereof. A systemVr other apparatus that uses one or more of the techniques 
and methods described here may ble implemented as a computer-readable storage medium, 
configured with a computer programWhere the storage medium so configured causes a 
computer system to operate on input anchor generate output in a specific and predefined 
manner. Such a computer system may include one or more programmable processors that 
receive data and instructions from, and transmit data and instructions to, a data storage 
system, and suitable input and output devices. 

Each computer program may be implemente<W a high-level procedural or object- 
oriented programming language, or in assembly or macnme language if desired; and in any 
case, the language may be a compiled or interpreted language. Suitable processors include, 

by way of example, both general and special purpose microprocessors. 
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snerally, a processor will receive instructions and data from a read-only memory 
and/or a random access memory. Storage devices suitable for tangibly embodying computer 
instructions aM data include all forms of non-volatile memory, including semiconductor 
memory devices^ such as EPROM, EEPROM, and flash memory devices; magnetic disks 
5 such as internal hatd disks and removable disks; magneto-optical disks; and CD-ROM disks. 

Any of the fotegoing may be supplemented by, or implemented in, specially designed 
ASICs (application specific integrated circuits). 

A number of implementations have been described. Nevertheless, it will be 

understood that various momfications may be made without departing from the spirit and 

j\o scope of the invention. For example, advantageous results still could be achieved if steps of 

=Ij the disclosed techniques were performed in a different order and/or if components in the 

; 5f disclosed systems were combined m a different manner and/or replaced or supplemented by 

^ other components. \ 

In addition, the systems, methods, and techniques described here may be 

j jij5 implemented in digital electronic circuitry, or in computer hardware, firmware, software, or 

r ] in combinations of them. Apparatus embodying these techniques may include appropriate 

input and output devices, a computer processor, and a computer program product tangibly 

embodied in a machine-readable storage device for execution by a programmable processor. 

A process embodying these techniques may be performed by a programmable processor 

20 executing a program of instructions to perform desired functions by operating on input data 

and generating appropriate output. The techniques may advantageously be implemented in 

one or more computer programs that are executable on a programmable system including at 

least one programmable processor coupled to receive data and instructions from, and to 

transmit data and instructions to, a data storage system, at least one input device, and at least 
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one output device. Each computer program may be implemented in a high-level procedural 
or object-oriented programming language, or in assembly or machine language if desired; 
and in any case, the language may be a compiled or interpreted language. Suitable 
processors include, by way of example, both general and special purpose microprocessors. 
5 Generally, a processor will receive instructions and data from a read-only memory and/or a 
random access memory. Storage devices suitable for tangibly embodying computer program 
instructions and data include all forms of non-volatile memory, including by way of example 
semiconductor memory devices, such as Erasable Programmable Read-Only Memory 
(EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash 
4p memory devices; magnetic disks such as internal hard disks and removable disks; magneto- 
of optical disks; and Compact Disc Read-Only Memory (CD-ROM disks). Any of the 
U J foregoing may be supplemented by, or incorporated in, specially-designed ASICs 
<l ] (application-specific integrated circuits). 

; 5 : ^"Accordingly, other embodiments are within the scope of the following claims. 



25 



